home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / general.programming / comp.programming_2215_000029.msg < prev    next >
Encoding:
Internet Message Format  |  1994-11-27  |  4.8 KB
  1. Path: dd.chalmers.se!news.chalmers.se!sunic!trane.uninett.no!nac.no!nntp-oslo.uninett.no!naggum.no!erik
  2. From: Erik Naggum <erik@naggum.no>
  3. Newsgroups: comp.programming
  4. Subject: Re: The Infamous GOTO
  5. Date: 25 Apr 1994 02:03:17 +0200
  6. Organization: Naggum Software; +47 2295 0313
  7. Lines: 74
  8. Message-ID: <19940425.1934@naggum.no>
  9. References: <nbschee.85.0010C93D@mailserv.nbnet.nb.ca>
  10. NNTP-Posting-Host: naggum.no
  11.  
  12. the condemnations of GOTO are based on the idea that programming a computer
  13. can be done without reference to or understanding of the actual computer
  14. being programmed and the less the programmer knows about the hardware, the
  15. better.  this is obviously false, and teaching this to wanna-be programmers
  16. is possibly the single worst offense against their intellect, their future
  17. career, and the against the software industry as a whole.
  18.  
  19. my tenet is that a programmer who is unable to read the assembly language
  20. for any given processor on which he programs, does not know what is going
  21. on, and should not be programming, any more than an architect who has no
  22. knowledge of actual structures or buildings should not design them.  (other
  23. aspects of engineering disciplines may or may not apply.)
  24.  
  25. the belief that GOTO leads to "spaghetti code" is equally obviously false.
  26. just because you _can_ do something, doesn't mean you will, or have to.
  27.  
  28. GOTO is not alone, however.  for instance, the C "break", "continue", and
  29. "return" statements are all variations on the GOTO theme, and allow exit
  30. from control structures to be more precisely stated than alternatives like
  31. setting variables that control the looping (thus introducing details of the
  32. loop behavior where it does not belong) and else'ing through enormous "if"
  33. statements (thus introducing mental overhead in reading the code), to
  34. mention two specific examples.
  35.  
  36. the extremely tiresome thread "REPEAT NO MORE" mentioned in its beginning
  37. some of the alternatives to loop control structures, and the need for a
  38. variety of them to support a variety of actual programming needs became
  39. obvious to most of the readers.  some languages allow labeled loops and an
  40. "exit" statement to exit a particular loop (Ada), which is just another
  41. GOTO in disguise, to give just one example, and a lot more elegant than the
  42. stupidity in the C language with only "exit the innermost loop" construct.
  43.  
  44. GOTO is fundamental to computer programming.  the key is not to ban it, or
  45. condemn it, but to invent better ways to express the uses to which it has
  46. been and may be put.  it is not a coincidence that the languages that
  47. purport to ban GOTO and variations like the C statements mentioned above,
  48. are very hard to read because of the clutter introduced to get around the
  49. lack of these features.  a major disservice to programmers and code
  50. reviewers alike, in the name of some misunderstood religious cause.
  51.  
  52. one of the perhaps best examples of the need for the functionality of GOTO
  53. without GOTO itself, is error processing.  IMNSHO, it makes much more sense
  54. to "goto error_handler" than to do a lot of processing in the middle of a
  55. function totally unrelated to processing errors in its assumptions about
  56. the operating environment.  with languages that has the "return" statement,
  57. this can effectively isolate the return points and _name_ them.  it is not
  58. a coincidence that GOTO-less languages and GOTOphobic programmers don't do
  59. error processing very diligently, and produce lots of code that violate
  60. Microsoft's look-and-feel "patent" on machines that freeze and crash.
  61.  
  62. languages that lack the GOTO family of control statements, must have many
  63. redeeming qualities to maintain a right to be called a _programming_
  64. language, not just contestants in academic beauty pageants.  functional
  65. programming languages satisfy this requirement in my mind, and I program
  66. more in LISP than in any procedural language.  however, when I do program
  67. in a procedural language, there's usually a GOTO for every 500 statements
  68. or so.
  69.  
  70. should beginners be taught to avoid GOTO, or should we all strive not to
  71. let beginners loose on production software?  programmers who don't know
  72. when and how to use GOTO properly, will _remain_ beginners, and it is
  73. better to teach them the reality of the world they will enter before they
  74. end up with a lot of bad habits and stupid religious notions.  it's just
  75. like PASCAL programmers who continue to write PASCAL programs in all known
  76. programming languages, even LISP.  the desirability of an over-protective
  77. upbringing is probably no higher for programmers than for other people.
  78.  
  79. best regards,
  80. </erik>
  81. --
  82. Erik Naggum <erik@naggum.no> <SGML@ifi.uio.no>  |  memento, terrigena.
  83. ISO 8879 SGML, ISO 10744 HyTime, ISO 10646 UCS  |  memento, vita brevis.
  84.  
  85. for information on SGML and HyTime, try ftp.ifi.uio.no:/pub/SGML first.
  86.